We have migrated all our users from Exchange 2003 to 2010 sp1. Some staff have been around for a long time and still have delegates or have assigned send on behalf to users that no longer exist in the org or have had their account disabled and mailbox removed. This stops them from editing delegates in Outlook and admins from being able to change send on behalf permissions. To get around this I have re-enabled the old account and recreated their mailbox. I can then remove the old user from the Exchange management console > mail flow > send on behalf and update delegates in Outlook. The main problem is there will be user objects that no longer exist but objects will still have a reference to their SID. On Exchange 2003 an invalid user would display the SID in Outlook and let you remove it from delegates but with Exchange 2010 it doesn't seem to be as forgiving. Anyone else come across this and (fingers crossed) have a fix? Cheers, Michelle

I think this is by design because in Exchange 2010 the SID is hidden once you disable/remove the mailbox in EMC/EMS. Try running get-disconnectedmailbox | select DisplayName, StoreMailboxIdentity, Database. This should list the SID of the user's mailbox and then you can manually remove the correct SID in Outlook. I hope this is what you are looking for.

Not exactly what I meant Michael. The names are displaying correctly in Outlook however I can't edit the list of those allowed to send on behalf in EMC nor can I remove an obsolete user from the list of delegates. When I click OK it gives me the error: "The Delegates settings were not saved correctly. Unable to activate send-on-behalf-of list. You do not have sufficient permission to perform this operation on this object". If I follow http://support.microsoft.com/kb/950794 then I can edit the delegates OK but I don't want to have to deploy this fix to all users with outdated delegates.

Have you tried to check with ADSIEdit? Access via ADSIEdit and go to the person that you the delegation has been set i.e. userA has access to userB. So go to userB properties and see if userA is in there in one of the attribute called publicDelegates and remove userA from userB. Let me know if you can get pass that.

Thanks Michael Vi! - Worked like a champ!

No probs Jeff. Here to help.